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Big Picture Background 


Airborne missions use satellite systems to connect on-board payloads 
and researchers to supporting ground equipment and scientists 


Each satellite communication solution carries different trade-offs 
Many missions utilize Iridium modems on-board the aircraft 
Some of Iridium’s benefits: 

— Provides services at the poles 


- Simpler, lighter antenna solutions, fits smaller crafts or tight locations 
— Cost savings — Don’t need to equip and carry multiple solutions 
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Iridium Link Characteristics 


e Iridium modems “go down” fairly often similar to poor cell phone service 
- Degrade: Some information is lost but the call is maintained 
- Drop: Total loss of link, similar to dropping a cell phone call 
¢ The fully operational system is slow by modern standards 
- Each Iridium link is rated at 2.4 Kbit/s or 300 bytes per second 
- Currently 4 channels are used to provide a total of 9.6 Kbit/s 
- Channels are bonded currently using standard Multi-Link PPP (MLPPP) 
¢ Simplifies network configuration — Single interface and address 


e Round Trip Time (RTT) Is very long (around 2-4 seconds) 
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Frequency of Link Transitions 
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Flight Date: November 18, 2016 Number of 


; ; Active Links Seconds Percent 
Flight Duration: 13 Hours 4 35643 76.26% 
Events that changed the number of active links: 3 8269 17.69% 

— 325 (25 changes / hour) 2 1969 4.21% 
. ae 1 235 0.50% 
Nearly one fourth of the flight is in a degraded state 
0 624 1.34% 
June 13, 2017 Www.nasa.gov 5 


John H. Glenn Research Center at Lewis Field 


Issues with Architecture 


e Airborne software on the flight computer acts as a data broker 
- Manually configured to control the data rate from each payload 
- Cannot adjust dynamically as the number of available links changes 
—- Resulting data rate is configured to a single scenario 

e¢ Network interfaces are in a default configuration 
- Tuned for modern terrestrial high capacity links 


e lridium speeds are slower than a 56K modem and require configurations to match 
¢ Bonded links create a single control loop 


— Network cannot discern losses between links 
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Issues with MLPPP 


¢ Best solution at the time - designed for bonding together multiple 
terrestrial connections and assumes fairly reliable calls or links 


e Fragments every packet across all active channels 
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COMPLETE DATA LOSS 
Ch 2,3,4 received correctly but discarded 
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Multi-Path TCP (MPTCP) 


A new (2013) set of extensions (TCP Options) to regular TCP which 
allows operation over multiple network links simultaneously 


Must be supported at both data endpoints 

Dynamically opens and closes streams or sub-flows to the destination 
— The number of sub-flows can fluctuate during the lifetime of the connection 
- Sub-flows are independently managed, each having their own control loop 
Provides a single byte stream between two hosts, like normal TCP 


- MPTCP manages data between multiple sub-flows into a single stream 
— Applications do not need to be aware of the change 
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Handling MPTCP Endpoint Limitations 


¢ MPTCP designed to work when at least one side is directly attached to 
the point of multiple interfaces (and thus paths) 


¢ Both endpoints must be MPTCP aware 


(a) 


Example, if all nodes have ea oan - 
MPTCP enabled, options Source Bodome —— Station Destination 


(a), (6), and (c) all benefit. . — 
However, option (d) cannot : (c) " 
as neither side knows the . 7 : 


number of paths. (4) 
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Service Specific Proxies 


e Used a set of proxies or servers using open source solutions for the 
types of services in use during flight 


— HTTP proxy (Squid) 

-— IRC server (unrealircd) — configured as a chat proxy (a “hub”) 
e Installed a proxy on each MPTCP system 

— Satellite communication CPU attached to the Iridium links 

— NASA ground station 
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Handling UDP Traffic and Networking 


¢ MPTCP Is TCP/IP specific 
— Needed a solution to “route” UDP traffic across all available PPP links 


e Network configured to transmit UDP data from payloads over all 
available Iridium channel(s) without fragmenting 
— Use smart queues to store only the latest data from each UDP source 
- Fairly limits all sources and adjusts dynamically 
— Will throttle all sources when TCP data is present or if channels are lost 


- Unburdens the flight computer — scales as the number of payloads change 
e Network parameters were adjusted to reflect the low capacity links 


-— Queues, initial windows, etc. 
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Example MPTCP HTTP Connection 


MPTCP Seq. Num. 
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10:48:00 10:50:00 10:52:00 10:54:00 
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Results 


e MPTCP did an excellent job of keeping connections active during 
multiple link transitions 
- Long-lived healthy connections that would have timed out with MLPPP 
- Dynamically leverage the amount of available resources 
- More responsive to link transitions 
— Overall more efficient use of the available capacity 
— More reliable communication 

e Service specific proxies worked well in conjunction with MPTCP 

¢ Beneficial to any system that utilizes multiple communication links 


¢ Being evaluated for fleet integration 
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Path Forward 


e Leverage current standards body work to eliminate the need for per 
application proxies 
— Some applications, like Secure Shell (SSH), would benefit 
— Allow for direct access to payloads, users while still leveraging MPTCP 
e Introduce network priorities and quality of service for packets 
- Allow classes of data to be prioritized over the low capacity links 
- Some data may be very important — introduce redundancy? 
e Example: Duplicating and sending the same information down all paths 
¢ Compression to further improve link efficiency 


e Address some limitations with the current MPTCP implementation 
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Thank you 


Questions? 
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